Talk:UBASIC/TutorialScratchpad
TutorialScratchpad Help: talk pages, talk page guidelines Av&Tv Commands That are very handy commands, thanks for finding out! Now if we only could read out in "M" mode what the cam thinks are the best settings for Av and Tv, we could make a script where it sets the right values automatically for us. Since the CHDK I use "M" mode so much, because fixed aperture and time values are great if you use the histogram to get the optimal exposure. But it really bugs me that I have to try so much to get the right exposure, because the cam only tells me "-2" till "+2", but not the correct exposure right away. --Harvester 19:26, 17 May 2007 (UTC) :Nice to see you guys finding those values for the these commands found in the source code (I'm still not sure about the MOD and CALL ones though, no reply to my questions about them on the main uBASIC talk page). I put the first list of values you people found in a table, because I couldn't see it properly formatted in my browswer. Then I checked into more Wiki formatting commands (found another nice total list here How to edit a page, and couldn't get the monospace (typewriter/tt) fonts working on my browser. Come to find out I had replaced that font in my settings. Oooops. Now the pre-formatted text shows up just fine. Should I undo the table I made or just leave it in case others can't display a monospace font properly? :Keoeeit 00:21, 18 May 2007 (UTC) ::MOD is just the name of reminder (%). CALL is not used at all. -- GrAnd 07:52, 19 May 2007 (UTC) :::Regarding the table: I think both formats are okay. Perhaps I like the shorter format a little bit more and you can copy&paste it better into a text file, so I changed it back (if it is okay for you). --Harvester 08:17, 19 May 2007 (UTC) ::::re: MOD & CALL, thanks GrAnd. I kind of thought that's what the MOD was for but wasn't sure. I'll try to not add any "call" commands to my scripts too. :-) Then again ... a print "Call 1-800-BUY-CHDK" as a subliminal ad in every 15th intervalometer shot might work. :-) ::::re: Table, yep, looks much nicer. The more I saw that blunder the more I saw the blunder by trying a table to fix a font problem on my end. If nothing else, I learned lots of cool stuff about making tables in Wiki-speak. :-) Manual focus button on S3 IS Any chance of the manual focus button on the S3 IS getting a command? It is very hard to keep the camera absolutely still while holding down the MF button. 207.216.12.82 18:51, 18 May 2007 (UTC) :I see this functionality has been added through the addition of the press/release option and the mf button. Thank you, that was fast. I will credit your software when user. HighInBC 00:35, 9 June 2007 (UTC) (was 207.216.12.82) Operations order Keoeeit, you said: :Normally we assume that operations such as * and / will be performed before any + and - operations. This is not the case in this uBASIC. You will have to be careful on what order you put your math operations. Do you have the example in which you got the incorrect result? I've tested a lot of variants of combinations of math operations and as for me they work absolutely correctly. FYI... Order of operations --GrAnd 12:18, 19 May 2007 (UTC) ::Well, I don't have any examples anymore. You fixed what was causing the problem. :-) I was having a rough time trying to sort out a way to get those math expressions to work in a Print statement. And that's what lead to my belief that there was a problem with the math operation hierarchy. And yes, I realized after I wrote which came first + - or * / that I had them backwards, but wasn't quite sure. Math class was over 30 years ago. I've devoted those brain-cells to new things since then. :-) (Or lost them along the way, which always raises an interesting question, how can the brain know when it has brain-damage? Paradox. :-) ) ::I'll check the tutorial math section and remove that portion that warns of math operation disorder now. And I could simplify my intervalometer script now too, now that the print + math commands is fixed. I really should add in a complete "total time =" command figuring in shutter-speed too, now that the get_tv values are known, but it might be a tight fit to get that all under 2K with a shutter-speed table. I wonder if there's a simple way to compute shutter speed directly from the tv value? ::What might be handy is if we start a bank of commonly used subroutines that anyone could just dump into a program, shutter-speeds computed from get_tv might be a good one for that. Ex: my count-down timer subroutine in the Ultra-Intervalometer script might come in handy for others. Keoeeit 14:53, 20 May 2007 (UTC) Logic Expressions I'd like to add a section in the tutorial on how to use the &, |, and ^ (and, or, xor) commands, but I'm not quite sure I could do it properly. (My BASIC being pretty rusty.) But for the sake of argument, can these commands be used in situations like: :if a=1 & b=1 then gosub "both_must_be_true" :if a=1 | b=1 then gosub "any_are_true" :if a=1 ^ b=1 then gosub "only_one_is_true" And can these be used in more elaborate truth conditions, such as: :if a=1 & (b=3 | c=2) ^ d=1 then z=3 & y=5 else gosub "subroutine" ??? And do these also have an operation hierarchy? (priority of operation) Keoeeit 14:52, 20 May 2007 (UTC) :These operations (and, or, xor) are not logic. They are binary. --GrAnd 15:09, 20 May 2007 (UTC) IAQ - Infrequently Asked Questions :-) Is there (or will there be) any way that a script could detect which camera model it is being ran on? I'd like to modify the Ultra Intervalometer script to have one more toggle so it would engage single-frame shooting or video mode (now that the S cameras have those commands), but it would be nice if when that is engaged it would go to the proper subroutine per camera model to engage video mode. With something like: if i=1 then gosub "axvideo" else shoot if j=1 then gosub "sxvideo" else shoot Then again, if there's no way to detect camera model, there could be one user-value set as 0, 1, or 2, for single-frame, A-series Video, or S-series Video, or would that be too confusing for the end user? I wonder if one more subroutine to trigger the camera's own timer would be overkill and redundant? So many possibilities to play with now! (Plus the discipline of trying to keep it all under 2K.) Keoeeit 06:19, 27 May 2007 (UTC) : How about putting the scripts in Categories like: Generic, A-series specific, S-series specific? (btw: thank you for checking the whole wiki for the new changes. Good work!) --Harvester 09:06, 27 May 2007 (UTC) ::re: Categories by camera series -- Not sure how that would pan out in the future, with so many cameras supported, each having their own unique interface, etc. Hard to say what would be the best tack to take on it. Not a lot of people are submitting new scripting code either (yet), so I don't know if putting them by series on their own Wiki pages or what, would be the best route. I think this is one of those "time will tell" thingies. I'll eventually add in the video toggle for the Ultra Intervalometer script, but the more I thought about, I realized I'm limited to 10 user definable variables too. (single letters at that, I'm running out of variables) I already used up 7 of them. :-) Now add in a Video toggle and I have to add script to set the duration for video too. There's 2 more user variables. 10 shot to hell already. Then I thought, I'd really like if if you had the option to take a full-frame shot before or after each video sequence as a documenting mode, as yet another option. Ooops, that's 11 variables. I'll think of sumpin! :-) ::re: the S-series button edits, I think I found them all, but if you spot one I missed feel free to change it. Keoeeit 04:07, 28 May 2007 (UTC) ---- Super quick question I couldn't find an answer to: how do you go back to the default script? Should I create a blank script with no functionality? Hope this is the best place to post this... --24.89.200.199 19:30, 12 September 2007 (UTC) Camera Operation Commands I think the section "Camera Operation Commands" could need some differentiation, like this: * commands (shoot, click, press, release) * the other "thing" behind the command... the buttons... you know what I mean (left, right, menu, display etc.) --Harvester 14:43, 2 June 2007 (UTC) ::Let me know if doing it the way I did was clear enough, if not and something seems confusing, or I shouldn't have used those graphics in the opening section, feel free to clean it up. My theory is always provide too much information than too little and let the receiver filter out what they need, rather than letting them guess on what wasn't said. As for the commands, some of the buttons should never need to use the press/release sequences (like erase, menu, set, etc.), even though press and release can be used with them (I presume). Since I'm not familiar with cameras other than the S3, I don't know what creative ways some might find for using them. So I prefaced them all with the click/press/release options. I now await the influx of amazing new scripts that everyone is going to share. (ya think? :-) ) Last night I got home late from a 16 hour fishing trip on my mountain bike, and rode the last 8 miles home in the dark on muddy dirt roads in pouring rain (4-lb bass on ice in saddle-bag), so the best I could do when I discovered the new press/release commands last night was update the "Focus Bracketing" script and test it on the S3, worked fantastic! (then I passed out and woke up 9 hours later) You have an A-series camera, correct? Can you modify or test that script and either add a confirmation note or add an A-series script if the one that I have up does not work on A-series? Keoeeit 18:57, 2 June 2007 (UTC) Dark-frame Subtraction not ALWAYS at <=1.3 seconds! I found out something interesting tonight, and I wasn't sure where to post this, but it could influence a lot of scripts that might already be or will be written. I was fooling around trying to find out the best ways to implement some button commands on my S3 IS, which meant I was really putting the camera through its paces with all sorts of things. At one point one of my scripts goofed up using a press "zoom_in" ... shoot sequence when I found out it was far far better to use a sleep delay with a press/release zoom_in command than a click "zoom_in" command. The interesting thing was that I actually got one photo to take a shot DURING a zoom, creating an honest-to-goshes zoom-blur image! I couldn't replicate this in a stand-alone script, but this is beside the point.. Anyway, I later went to go put some tweaks on the Lightning Photography script for the S3 IS, trying to make it even nicer, having it use a press "mf" / sleep-x / release "mf" command to set the camera to infinity focus. After a few times of running that script i noticed that my 1-second frame rate got SLOWWWWW... and I was getting the typical "busy" in the view-finder for a dark-frame subtraction taking place. Uh oh, I thought maybe I found the very first occurrence of CHDK goofing up my firmware. It was doing dark-frame subtractions all the way up to 1/6th of a second! Only when I put it to 1/8th of a second would the dark-frame routine cease. I went to go find another SD card without CHDK on it, I even removed the little button battery to reset my camera's firmware. Then I was able to get 1/6th seconds without a dark-frame. I thought, awwww $#|T, I bet I busted something, oh well, the rest of everything works just fine. Then I got the idea of something ... I opened up the LCD display on the back and felt the back of the camera, it was VERY warm from all I was doing with it. I wondered .... could Canon be so smart as to increase the dark-frame subtraction as more thermal energy was causing more noise??? I let the camera set a while to cool down. I have my no-dark-frame-subtraction back again at 1-second shutter speeds. Too much heat from over-use (or leaving it in a warm place) will cause your dark-frame routine to kick in at higher shutter speeds! I wonder, if you put your camera in the fridge for a bit if you could get dark-frame-free exposures at shutter speeds even lower than 1.3 seconds? I may test this. What a boon that would be to astrophotography in the winter months! (I wonder how cold the camera would have to be to have no dark-frame subtraction at 15 seconds. :-) ) So, I didn't know where to post this anecdote and findings. I discovered a lot about the script commands as well as the dark-frame routines tonight. Perhaps someone can say this in a more concise way and post it where others might see it. Maybe put in a note that if running lengthy scripts where you need no dark-frame-subtraction to kick-in, to open up your LCD panel on the back (un-lit) so the camera body can keep cooler. p.s. I found it's much better to use a press/sleep-x/release "timer" sequence than a click "timer" command. Less chance of the command not getting implemented while the camera is busy setting exposure and stuff. So those press/release commands are going to come in more handy than I first thought. The press "zoom_in/out", sleep-x, release "zoom_in/out" is another good way to use them, MUCH faster than a for/click "zoom_in"/next loops! Keoeeit 11:54, 6 June 2007 (UTC) :Yes. I heard that Canon uses thermistor to measure sensor temperature to make a desision on dark-frame substraction. This mechanism exists in my A610 as well (the minimum Tv is the same - 1/6th). In the same time if Tv >= 1.3s the dark-frame substraction is always performed. So, you can't avoid the dark-frame substraction at 15 seconds even if you put your camera into a freezing room. :) --GrAnd 13:36, 6 June 2007 (UTC) ::Ah, thanks for confirming what I observed and the further info on it. This will save me from putting my camera in the deep-freeze in a desperate attempt to get rid of the dark-frame routine. Or tying a block of dry-ice on top of the camera. :-) You would think they could mention this in the manuals or something. It was a bit disconcerting at first. If I notice a good place to mention it in the main Wiki scripting info I'll do that since it's not documented elsewhere. I notice you just updated CHDK, I have to go grab my copy and check it out. Thanks-again for the info! (AND CHDK!!) :-) Keoeeit 21:50, 6 June 2007 (UTC) :::Very interesting, thanks for the S3 IS info. HighInBC 14:10, 11 June 2007 (UTC) Deterministic ISO settings Is there a reliable method to set the ISO to a deterministic value? I want to initialize as many settings as I can to specific values in the beginning of my script. The only way I've found to set the iso value is by click'ing the 'ISO' button, and since it rolls over, you can only set it relative to the initial value. (for instance, if the ISO began at 100, if you click 5 times, you get back to 100 (100->200->400->800->80->100...)) But I haven't found a way to guarantee I have it set to 80. Poking around in the source code, there are tables defined for the shutter speeds, aperture and ISO values. There are set_tv and set_av to set the shutter and aperture, but no equivalent for setting ISO. Is a 'set_iso' operation possible/in the works? An alternate possible approach would be to use some sort of 'reset' operation to reset everything to some known default value, and then go through and set everything to the desired settings. Any suggestions? CHDK is great! Thanks! Get_Focus X? This request is now obsolete due to Build 125. :-) but I'll leave it in for the info about the S3's SET button + MF feature, someone might make use of that some day. GrAnd? I read somewhere that it is easy for you to read the manual focus position but not set it. Would it be possible for you to implement a simple get_focus command. With this I can see all kinds of ways where a near-exact focus distance could be set. For example, in the S3 IS camera it could be done with: rem set manual focus to nearest possible on S3 IS press "mf" press "down" rem 8 seconds is needed for full manual focus travel at highest zoom setting sleep 8000 release "down" rem Going to set manual focus to 1256 mm :coarsefocus get_focus x if x>1200 goto "finefocus" rem increment the manual focus a bit each time it loops press "up" sleep 10 release "up" goto "coarsefocus" rem Fine-focus routine :finefocus get_focus x if x>1255 then goto "shootpic" click "set" sleep 100 goto "finefocus" :shootpic whatever code you want after focus is very very close The sleep commands would have to be tested, but as long as you can detect what the focus position is, then it's possible to stop the manual focus position where it needs to be. In the S3 IS in MF mode you can press the SET button for fine-tuning manual focus, and it always works from near to far (in micro-increments) until it locks on something with high contrast. This is how you could emulate a fine-focus mode. Keoeeit 19:26, 11 June 2007 (UTC) Consolidate the original Syntax & Tutorial Pages? When this all started out, and GrAnd put together the preliminary pages for us to get this rolling, I started this "Tutorial Scratchpad" page (because I didn't know what I was doing yet/still :-) ) with the idea that sections of this scratchpad page could be eventually copied and pasted to GrAnd's original uBASIC Syntax page. Well, it seems that it just got easier and easier to add on to this one by me and everyone else. I still like the way GrAnd described some things so I thought his page should always stay. But I think it's getting to that point where his original page should be consolidated into this one (or vice-versa), and the final page renamed to, perhaps, just "Script Tutorial", or "CHDK uBASIC Scripting" or something like that, or ... I don't know, whatever would be the most correct title to use. And would this require putting it all in a new Wiki page with the right path-name in it? Or can a Wiki page/path be renamed? So, would anyone like to take a stab at how to do all this? I'm wondering if GrAnd's page could be put in as a header section where the "Starting Out" info was put. His shorter summation of the commands available with the the rest of the tutorial following. As well as taking his script examples and peppering them in places where they might be the most applicable. Comments? Suggestions? Is this needed or not? Anyone want to step up to the plate and do it? :-) Keoeeit 16:37, 12 June 2007 (UTC) set_zoom problem This is odd, because it was working before. I would use the script: set_zoom_speed 50 set_zoom 61 end to set the zoom to a specific point for a shot I wanted. It worked, several times. Now when I do it, the camera goes to the correct zoom level and automatically stops. I read about how this can happen with a zoom speed of 5 or less. But I tried 100, 50, and 10 with the same results. Could there be another explanation to the behaviour? It would be my HDR mosaic photography if I could instantly set my ISO, Av, zoom, and focus. But I just can't get past the zoom setting. HighInBC 22:35, 30 June 2007 (UTC) BATTERY VOLTAGE Can I use a command to read the battery volage and then perform another command depending on the voltage or voltage change? :This has been added by Microfunguy's SDM, and Fingaolo's special builds. See the Scripting Tutorial in the Camera Commands, Special Builds sections. Motion Detection Version? I asked some questions about it in another spot in this Wiki. I'm not sure if it will be seen there so posting a link to that question here: Motion Detection, add to the Tutorial? :Situation resolved. :-) Access to Real time clock? Is there a function to retrieve the internal real time clock value? In attempting to deal with the timing of intervalometer scripts, it seems like so many factors can affect the overall interval time. The sleep function used to space the interval needs to at least estimate what the those other things are (exposure time, time to set focus, time to determine exposure, writing to card, dark frame subtraction time, etc). All of this guesswork and mode- and conditions-specific variability could be ignored if the script could fetch the RT clock value, and just shoot at the appropriate time. If there is not such a function, could I get it onto the wish list? Something that returns an integer equal to the time of day (in msec, or whatever units the camera uses). Thanks, Divalent ERASE COMMAND, and other problems hi, if recently, 3 days ago, came across CHDK....... and i love it . thats why i decide to give an comment here.... most of the scripts wont work if u not put the cam in a certain situation(condition).... one of the most common faults i found is the use of the erase command... if this is used and in the config the raw shots are enabled the cam is getting totally confused and crashes... HOW to prevent this ... what makes me suspioues that I couldnt find any hints nor comment about this in the scripts descriptions... the next problem i discovered is that some of the scripts are using divisions where the result is NOT an integer that even hangs up the cam even...As far as i understand uBasic its needed INTEGERS to work proper... the fact of this problems and none descriptions of the unknown cam settings where its been used make the most scripts non usable and a newbie like me gets puzzelt quite a bit... overall i think the idea of the script is a good way which needs to be adjusted a little bit to make the program even more unique then it is allready.dont get me wrong I love it....it is awsome except this small matters ...... is there any solution or chance to corect this... like reading the parameters out of the cam and let it run into an error trap.. like its used in MBasic or other basics .... something like on error goto... i havent enough knowlege yet but i guess the cam gives out some errorcodes in the memory or firmware ........ any suggestion....... many greatings from germany ... hells_bells27 :I've never noticed this integer-only problem that you seem to be having, and I've written and tested many scripts using divisions that result in non-integer values. The non-integer values from any calculations are always rounded to integers whenever they are used in any resulting variables for camera commands and print statements. Perhaps you are just copying the scripts wrong? People using Mac computers frequently have this problem. Or those that use anything other than the simplest of text editors. This is the first time I have every heard of anyone thinking this might be a problem, i.e. integer/non-integers in scripts. I've also never ran into an erasing files causing crashes. You might have to explain in detail exactly what you are doing that causes this so that others might be able to duplicate it. Be sure to also state what camera and build of CHDK you are using. That can make a huge difference. Property Case values. A working exploration section Some inital tests related to the property case values. This section is for exploring the values stored in these variables and the effect of changing them to different numbers. Please help out and add info from more camera's and more properties! You can use Fingalo's CHDK build or a pre-release version of 'StereoData Maker' available here . (An example-script is provided with SDM that cycles through the white-balance settings using set_prop command). I used the script I posted in the user scripts page to test some of the property case values. can find that script here: http://chdk.wikia.com/wiki/UBASIC/Scripts:_a_property_case_value_tester I only looked at a subset of the property cases that others have identified. I didn't specifically try to identify more, although I did discover #32. I tested these on an S3, in P-mode. Here's what I've found so far: For the following "properties" here are the values I obtained: 6 Drive mode ---------> 0 - single, 1 = continuous, 2 = timer 9 Metering mode ------> 0=eval 2=center, 1= spot 11 Macro --------------> 0,1,5 for norm, macro, and super 12 Manual Focus ------> 1 = manual, 0 = auto 14 Selftimer delay ----> (looks to be time in msecs, mine was 10000, when set at 10 sec) 16 Flash mode ---------> 2 if flash is closed (down). if open (up) then 0 if auto, 1 if ON 21 ISO value ----------> 0 if auto, 1 if ISO-HI, or actual ISO (80,100,200,400,800) 23 Image quality ------> 0,1,2 from best to worst 24 Image resolution ---> 0,1,2,4,8 for L,M1,M2,S,W 25 EV correction ------> plus or minus 32 for each 1/3 stop (in other words -32 for -1/3 stop, -64 for -2/3 stop, -96 for -1 full stop, etc, and positive values for over exposure by equivalent amounts) 26 EV correction ------> (same as #25) 32 Exp bracket range---> (Same units as 25/26: e.g. 96 = +/- 1 stop range) 126 Video Frame rate----> Units of fps (e.g. 30) *beware of changing! I tried changing #126 the Video fps to 10, and it behaved strangely (time counter went really fast) when I started a video, and then the camera crashed when I stopped the video. The video was not saved on my memory card. Beware! For #6 drive mode: it does not appear that changing these has any effect, at least to the extent that, if I change it, and then exit CHDK menu mode and press the shutter button, it only takes a normal shot. (ditto for the flash #16; see below) I didn't try to change 9,11,12,or 14 and see the effect on images. For 25 and 26, I'm not sure why there are two of these, and I'm not sure what would happen if you change one but not the other. It's not related to the exposure bracket settings (see 32). My suggestion is to change them both if you want to use this to change the EV. UPDATE: you can set this to get exposure compensation of + or -4 (at least)! (I set both to +384 or to -384), and got a exposure that was 4 times over and under exposed (way blown out, or nearly pitch dark!)) Note: for items 21, 23, 24, and the 25/26 pair, I did a test where I was able to change them and then shoot an image that reflected those changes. Specifically, I changed the ISO to 800, IQ to 2, Im Res to 4, and EV to +1, and the resulting image was 640x480 and the exposure and aperture were consistent with an image at the setting I changed them to (compared to an image without those setting). However, I will note that upon exiting the script, the camera display (and menus) did not reflect the new values; but if I immediately shot an image again, the image was shot at those altered values (despite the fact that the camera display show their original, former, values). Turning the camera off, then back on, did restore the original settings to reflect what the camera display said they were. So, if you change these items in a script, it is probably a good idea to change them back before exiting, or your camera will be confused. I also tried to change the flash from its initial setting of auto to ON, by changing #16 to 1 (with the flash up). However, that did not result in a shot with the flash firing. However, you could use the get_prop command to find the state of the flash, then use the press flash to change its state (although if its not up, then you can't find out; but then again, it doesn't matter cause the flash won't fire!) -Divalent :Most excellent testing and sleuthing there Divalent!! Thanks!! This information will be extremely valuable to add to the pages. You might want to go ahead and add them to the set/get_prop section now. With a note of what camera model you have found them to be correct on at this time. :This is the same way that people who were testing the various set/get_av/tv values were found for different cameras (see that section, examples still intact there). One person posting theirs encouraged other camera-model owners to test theirs. Some discrepancies were found and it resulted in some minor changes to the look-up tables in CHDK so all cameras would have the same values. :Again, excellent info! Thanks for finding this stuff! (I've not had time to test things during my busy summer months, but that's winding down and I can do more this fall and winter.) :It will be interesting to also see the various video mode values. I still wonder if non-standard resolution and frame-rates might not be available hidden in the secrets of these cameras. Hmm... I wonder if a prop_id will be found for audio-recording settings too. Or maybe even the sound-memo length (as was asked as a request recently). So much to discover yet. :-) :anon :p.s. Could you expound a little more on how the EV correction values are used? That could be a fantastic addition for use in bracketing and HDR scripts. :: I'm really not certain what the purpose is of having two seemingly duplicate variables. I did some further testing and the both are the same even if you put the camera in EV bracket mode, so that rules out that function as the reason for the two variables. My suggestion would be to be cautious and change them both if you want to change one. :::I'm not sure either why there might be 2. But when writing scripts I did find an interesting aspect to the Av and Tv values. It appears that the one being detected and the one you set are two very different things. I can't remember the exact situation in what caused this, I found it when trying to write the Lightning Photography scripts. Using the set_av/tv commands. When I saw that the Prop_ID values listed the Av/Tv as "coming Av", and "coming Tv", it sort of reinforced what I sensed was going on. Maybe these 2 values are used similarly? One for manual settings, the other for auto-detected settings? Just a vague guess. As far as their use, it wasn't clear from your list if the numbers -32 to +32 are used to set 1/3rd stop or what, or if the full range of numbers is -96 to +96. And if that's the case, can they be extended to change the stop by 2 or more for HDR frames? How far can those numbers actually span? mr.anon :::: Great suggestion! so I tried it and YES, you can at least use it to go (at least) + or - 4 stops. (Confirmed with actual photos. Do you want more?) I clarified the units above; e.g. to go + or - 4 stops you set them to + or - 382.